下圖是假想的團隊組織圖 :

總經理室成員 - 總經理
業務部成員 - 業務部經理、業務專員x10
產品開發部成員 - 開發部經理、後端工程師x3、前端工程師、資料庫分析師
系統運維部成員 - 運維部經理、運維工程師x6

總經理管理業務部經理、開發部經理、運維部經理。
業務部經理管理10位業務專員。
開發部經理管理3位後端工程師、1位前端工程師、1位資料庫分析師。
運維部經理管理6位運維工程師。

有別於上述所列的職稱角色，在 Scrum 的架構下，只有三種角色 :

1. Product Owner (PO) - 產品擁有者 ;
2. Scrum Master (SM) - Scrum 導師 ;
3. Developer (Dev) - 開發人員。

在開發的階段，或者更專業一點的說，在規劃 Story 的開發過程中，Scrum 角色可能如下列表格 :

• Scrum 角色只挑選具備執行該任務能力的成員。例如: 開發的過程中，沒有業務部的人員參與。
• 同一人可以身兼多個 Scrum 角色。例如: 開發部經理既是SM，也是一位Dev。
• Scrum 的每個角色可以由多位成員擔任。例如: Dev就是產品開發部與系統運維部的所有成員。

簡單的說明一下這個假想團隊的 Scrum 角色配置理由。PO的角色無庸置疑的是總經理，因為總經理本身就是實質產品的擁有者。總經理同時必須扮演SM角色的理由在於總經理是決斷者。而開發部經理也扮演SM角色的理由則是因為具備實質完成所有開發項目的專業技術人員 ; 更白話的說，就是「開發接力賽的最後一棒」。

Scrum Master(SM)必須具備相當程度的專業能力及決斷權力。

無庸置疑地，會成為開發部經理的成員，也必定歷經過大大小小的程式專案才能成為該職缺的當選者。或許有人會好奇，為什麼運維部經理不是本例中的SM ? 這個問題答案，之後介紹假想的開發專案需求時，或許會更容易理解。而且，就自己10餘年來的程式開發經驗，資深的程式設計師都能自己架構自己的開發環境，運維方面的知識也是足夠應付的。

為了讓接下來幾天的開發任務更容易釐清開發進度，我們將昨日的 Scrum 看板調整如下 :

Scrum 看板的調整，在整個 Scrum 開發過程中是非常常見的。

Scrum 看板的目的，只是幫助所有成員快速了解每次衝刺活動(sprint)的具體目標。

至於什麼是衝刺活動(sprint) ? 接下來的幾天會從案例說明。